ATM switches can be classified into three categories: basic switches, smart switches, and intelligent switches. Basic switches perform preliminary switching functions and sometimes operate in the hundreds of Gb/s throughput region with multi-Gb/s port rates. However, they cannot support multicast, transmission from a source host to a selected group of more than one destination hosts, or other special functions, for the reasons discussed below. Many commercially available ATM switches fall into this category. Intelligent switches, on the other hand, suffer from technological limitations associated with being software based, and therefore cannot operate in real time, except for lower-throughput switches. (Routers, most of which operate below 100 Mb/s, are one example of intelligent switches.) ATM switches which fall into the smart switch category, support multicast and broadcast transmission from a source host to all hosts on a specified network. These switches can operate in the tens of Gb/s throughput region with port rates in the hundreds of Mb/s.
There is currently a transition from basic ATM switches toward smarter switches that support multicast, and a transition from intelligent router-like switches toward faster ATM switches that support new high-bandwidth applications with quality-of-service requirements. Furthermore, new TV distribution services are likely to accelerate the transition to smart switches.
To support multicast, a source switch must be able to receive an acknowledgment ("ACK") from each multicast destination switch. Thus to achieve reliable delivery in a multicasting environment the source host must be capable of processing the ACKs for a potentially large number of destinations. When the source system receives more ACKs than it can manage, a situation known as `ACK implosion` results and system efficiency suffers.
Protocols have been proposed at higher layers, including transport through application levels, that provide processing to support a `combine function` in which ACKs, for example, are combined logically before being passed to the source application. See for example, U.S. Pat. No. 5,541,927 issued to Kristol et al., on Jul. 30, 1996 which describes a method for a high speed multicast protocol. Typically, the combine function would be located at the branches along the multicast tree so that the source would not be inundated with messages.
While supporting a combine function with software is useful, it is relatively slow. As the hardware integral to multicasting switches can duplicate cells quicker than the software implemented combine function of the prior art, the software solution acts as a bottleneck decreasing the throughout of the multicast connection.